Kubernetes完全ガイド 第2版

https://gyazo.com/5ff57a118f80b2ec04f41fe9728385dd

CNCF

スケジューリング

どの Node に配置するか

Affinity / Anti-Affinity

セルフヒーリング

Node 障害時に別の Node にコンテナを振り分ける

Kubernetes 設定のデータストア

minikube

hyperlit

kind

ローカルでマルチノードクラスタ作って試せる

brew install kind

FeatureGates

beta 以上はデフォルトで有効、alpha は明示的にゆうこうにする

Flannel

Pod 同士のネットワークを構成する

GKE

プリエンプティブルインスタンスを利用して費用を下げる

$ gcloud container get-server-config --zone asia-northeast1-a

NodePool

ノードにラベル付けしてグルーピングする

Playground

GKE 準備

必要になったらやる

BRAC

$ kubectl create clusterrolebinding user-cluster-admin-binding

Workload Identity

基礎

Master / Node

リソースのカテゴリ

Workloads

Service

Config & Storage

Cluster

Metadata

Namespace

クラスタを仮想的に分離

デフォルト kube-system, kube-public, kube-node-lease, default

チームや環境で分ける

クラスタアップデート, マニフェストの再利用性, Service の名前解決

kubectl

clusters / users / contexts

context = clusters + users + namespace(optional)

$ kubectl config

$ brew install kubectx で入る

kind でちょっと立ててみる

$ kubectl create -f sample-pod.yaml

$ kubectl get pods

$ kubectl delete -f sample-pod.yaml

$ kubectl delete pod sample-pod

$ kubectl delete-f sample-pod.yaml --wait

--wait で終了を待つ

$ kubectl apply -f sample-pod.yaml

前回適用したマニフェスト、現在のリソースの状態、今回適用するマニフェストから差分がでる

Server-side apply

差分検知は手元との差なので衝突する

--force-conflicts

フィールドを管理しているコンポーネント = manager

kubectl get pod sample-pod -o yaml

--field-manager=

$ kubectl rollout restart deployment sample-deployment

$ kubectl wait --for=condition=Ready pod/sample-pod

$ kubectl wait --for=condition=PodScheduled pod --all

マニフェストファイルの設計

1つのマニフェストに複数のリソースを定義

実行順序を厳密にしたい場合、リソースの結合度が強い場合

複数同時適用

ディレクトリで適用, 細かくディレクトリ分割すると適用順序の制御は難しくなる

アノテーションとラベル

どちらも metadata 直下

アノテーション: システムコンポーネントが利用する

GKE, EKS 等環境特有の拡張機能

ラベル: リソースの管理に利用する

$ kubectl get pods -l label1=val1,label2

ラベルに対してレプリカ数を制御したり、ラベルに対してトラフィックを流したり

$ kubectl diff -f sample-pod.yaml で差分を見る

$ kubectl api-resources

Namespace レベルのリソースとクラスタレベルのリソース

$ kubectl api-resources --namespaced=true # Namespace

$ kubectl api-resources --namespaced=false # Cluster

リソースの確認

$ kubectl get pods

$ kubectl get pod NAME

$ kubectl get nodes

$ kubectl get all

--show-labels

--output=FORMAT

custom-columns=GO_TEMPLATE

$ kubectl describe

$ kubectl top node

$ kubectl top pod

$ kubectl exec -it sampe-pod -- /bin/ls

デバッグコンテナ

$ kubectl alpha debug sample-pod --image=... --container debug-container

$ kubectl exec -it sample-pod -c debug-container -- bash

ポートフォワーディング

$ kubectl port-forward sample-pod 8888:80

local:container

ログ

$ kubectl logs sample-pod

$ kubectl logs sample-pod -f

-f で follow

ファイルのコピー

$ kubectl cp sample-pod:etc/hostname ./hostname

プラグイン

$ kubectl plugin list

verbose

-v=level

$ kubectl -v=6 apply -f sample-pod.yaml

$ kubectl -v-8 apply -f sample-pod.yaml

Pod < ReplicaSet < Deployment

Pod < Job < CronJob

Pod で複数コンテナ動かす

サイドカー: 機能追加, データの扱い系

アンバサダー: 外部との中継, Cloud SQL Proxy

アダプタ: 外部からのアクセスのインターフェース

ENTRYPOINT が command CMD が args

hostNetwork: true

基本 NodePort Service を使う、同じ Node 上で port 取り合いになる

dnsProxy

ReplicaSet

$ k describe rs

ラベル重複など管理がミスったときに削除されうる

セレクタ

environment = production

environment in (production, qa)

Deployment

$ k rollout status deployment DEPLOYMENT

ローリングアップデートの際に通信待つとか Gracefull Shutdown になってるのかとか気になる

更新して戻したものを apply すると以前の ReplicaSet が再利用される

$ k rollout history deployment sample-deployment

$ k rollout undo deployment sample-deployment

spec.strategy.type

DemonSet

Node ごとに1つPodを置く

ホスト単位でのリソース収集やログの収集など

StatefulSet

DB など

PersistentVolume

Job

終了を前提としたもの

並列数、成功回数

spec.ttlSecondAfterFinished

CronJob